Building a user story to share knowledge
In my first story ‘User Experience is …’ I promised that …
"over the course of a few stories, I’ll try and cover a few of the sciences we draw upon in our art as a creative community to create engaging experiences."
In my last story I talked around how User Experience is … applying ethical design. This time we look at how we need to implement value and certainty within the creation of user stories to deliver the value we design in.
Building a user story to share knowledge
Many of the questions and queries I read and get asked about from the UX community is how it’s best to work in sprint with engineering teams.
The agile principals hasn’t really been solved for design. This is evident when we’re defining products and trying to integrate a design framework in other people’s workflow. However here are some thoughts that are shared amongst the product, agile and design community.
After all only when a product is shipped and made available to its end users is it able to realise its value. Without it being in the wild the value of a product or feature isn’t realised and the value is unable to be gained. This too is where the true value of the design and experience of a service, product or feature is able to be claimed and realised. Otherwise design becomes an academic exercise with beautiful designs adorning walls of offices and not making it into the products they belong to!
So this is an important relationship in User Experience, as engineering truly bring designs to life. To function as ‘highly performing’ teams, engineering teams have a slightly different need from how work is handled and how they work as a team, so their ways of working too is a little different.
And understandably, but that doesn’t mean that designers have to force themselves to work in that way too, especially when it doesn’t fit or feel right. It just means that we need to understand the needs and how they do work, to enable us to work with them effectively, even if we work in a slightly different way ourselves. They are ultimately another set of users that we need to understand and empathise with. But instead of designing a product’s experience, we need to design a workflow that works for us, for them and the whole team to improve the team’s experience and performance.
We as designers need to understand when and where it’s right to develop and share knowledge and at what level is useful for the individual and the whole team. This allows us to build understanding in the sprint ceremonies and ultimately get a user story ready for sprint, with the least amount of friction and time possible.
Fundamentally how designers need to work with engineering teams, is making sure we are slightly ahead to provide a bit of guidance and certainty for the engineering teams to understand the work they need to do.
If we simplify it in this way, it’s all about the duality of sprints to ensure we work ahead and focus on the user story workflow. Let me explain …
Danny Virgil, the end-to-end product design process
Dual track sprints allow a discovery team to explore ahead in a product backlog or roadmap to understand the problems that are trying to be solved better, be able to complete research, form hypothesis and test ahead of the engineering team. They can be thought of a scouting team to make sure the way is known and safe before the exhibition (engineering) team.
It’s a little unrealistic to think that designers can create meaningful user-centred designs or craft a larger UX strategy in rapid sprint iterations. No matter how focussed, organised and efficient you are, 2 weeks is just not long enough most of the time to be able to find a robust enough solution and be able to execute it with an effective design. This can often lead to clunky and disjointed experiences and inconsistencies in the design language being used.
However allowing designers (and those with a detective mindset) the time and space to conduct research and user testing can pay dividends later in the product lifecycle. To find out more about the different mindsets involved in providing certainty I’ve written a short post on how User Experience is … providing certainty, so if you want to know more have a quick read.
Danny Virgil, Dual-track design sprints
Forming a discovery team that includes the right mindsets, which is normally a product manager, a user experience designer and any subject matter experts required to deliver a validated solution. The team works well ahead of delivery to uncover problems, define requirements, explore solutions and validate solution designs. Normally the team follows a standard design framework of Understand, Explore, Build and Test.
If you’d like to know more, listen to Damon Dimmick — Vice President of Product Management & UX, speaking on UXPin about design spikes and the dual track agile process
Damon Dimmick speaking on UXPin about design spikes and the dual track agile process
User story workflow is similar in that it provides more certainty and turns unknowns into understanding and allows the team to have less surprises. This builds shared knowledge amongst the team so they are comfortable to play a story into sprint.
Joseph Luft and Harrington Ingham, 1955
The story workflow ranges from inception of an idea all the way through to delivery within a sprint and ultimately the release of functionality to the end users to realise its value.
Very closely tied with the concept of dual sprints, user story workflow shares a lot of values and concepts in order to be able to deliver a user story to an engineering team and for them to feel comfortable to take on the work and deliver it in sprint. The user story workflow looks something similar to this:
Story workflow, following agile and design framework principals
This process is a guideline, so use it to enable you to build user stories however fits with your team, stakeholders and the cadence of when you get together.
Next up I’ll look at what design frameworks are and how you can best use their tools and techniques to design better solutions to problems, to explore how you can use design frameworks to guide solutions.
Originally written as part of the ‘User Experience is …’ series for UX Collective.